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(54) Application software damage detection and repair 



(57) A method, system, and apparatus for detecting 
and repairing damaged portions of a computer system 
is provided. In a preferred embodiment of the present 
invention, a damage detection and repair facility moni- 
tors and detects changes to the computer system. The 
damage detection and repair facility compares these 
changes to the set of constraints defined by the working 
definitions for each application installed on the computer 



system. The working definitions define the invariant por- 
tions of each application and define the constraints 
placed upon the computer system by each application. 
Responsive to changes that are in conflict with this set 
of constraints, the damage detection and repair facility 
makes such changes in the persistent storage so as to 
resolve these conflicts. This may be done, for example, 
by repairing a damaged file, installing a missing driver, 
or adjusting an environment variable. 
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Description 

[0001] The present invention relates generally to the 
field of computer software and, more particularly, to 
methods of detecting and repairing damaged files and 
settings within a data processing system. 
[0002] Currently, computer systems are built up 
through a series of installations provided by different 
software developers, each of which installs one or more 
different software components. There is no industry 
standard way to describe what comprises an applica- 
tion. Without this description, there is no way to imple- 
ment a standard service that can protect the integrity of 
each application. 

[0003] There is a need for a standard, simple, scala- 
ble, platform independent mechanism for detecting 
damaged applications and repairing them. Applications 
can be damaged in a variety of ways. Each of the fol- 
lowing operations can damage one or more applications 
within a computer system: 

• Installation of new applications 

• Reconfiguring applications 

• The use of an application 

• Application error 

• User error 

• Viruses 

Installation is dangerous because the current approach 
in the industry is a rather ad hock approach in which the 
responsibility for the installation procedure for each ap- 
plication rests with each application's developer. During 
installation, any error or conflict between any two or 
more applications may potentially corrupt the computer 
system configuration. Applications do not have access 
to the requirements and dependencies of the other ap- 
plications already installed on the target computer sys- 
tem. Without this information, no modification to a com- 
puter system's files and settings can be made complete- 
ly safely. Yet the modification of files and settings is re- 
quired to install applications onto computer systems. 
[0004] The reconfiguring of an application may also 
require that changes be made to files and configuration 
settings needed or used by other applications, and such 
changes may render one or more of the other applica- 
tions inoperable. 

[0005] The use of applications may also require that 
the files and settings within a computer system be up- 
dated from time to time. This requires applications to be 
"well behaved" with respect to each other. Conflicts may 
still occur, either by chance, or error within an applica- 
tion. Yet the application developer's priority is always to 
their application without regard to potential conflicts with 
other applications, except to insure their application 
wins such conflicts. Because the requirements and con- 
straints of each application are not defined, each devel- 
oper also becomes responsible for supporting the con- 
figuration management of every system on which the 



application is installed, and for handling conflicts in all 
configurations in which their application may be used. 
However, this responsibility is rarely, if ever, each appli- 
cation developer's top priority. 
5 [0006] The current system of deploying and running 
applications defines only very weak barriers between 
applications to prevent a given application from damag- 
ing other applications. Any conflict, if handled in the giv- 
en application's favor, may prevent a competitor's appli- 
10 cation from running. This state of affairs provides little 
motivation to avoid conflicts with a competitor's applica- 
tion so long as the developer's own application can be 
configured properly. Each application is dependent on 
its own installation and runtime code to verify its config- 
13 uration and access to prerequisite devices, drivers, ap- 
plications, and system settings. 
[0007] Users themselves may cause problems by 
modifying files or configuration settings, either by acci- 
dent, failure to follow a procedure properly, etc. Often 
all the files and configuration settings are exposed to 
modification by the user. 

[0008] In reality, virus attacks account for a very small 
percentage of all application failures. Yet a viral attack 
can result in a huge amount of damage. 
[0009] Currently the generally accepted method of 
protecting a computer system from damage from out- 
side viral attacks is through the use of third party vendor 
virus protection software products. However, these 
products must be updated frequently to be able to detect 
the latest viruses. Any new virus that has been created 
since the software was updated may be undetected by 
the virus protection software, thus enabling that virus to 
corrupt or destroy files necessary for the proper per- 
formance of the computer. 

[001 0] Therefore, one needs to be able to strictly de- 
fine an application's runtime representation. A Compu- 
ter system, on the other hand, must allow modifications 
and changes in its persistent state in order to make the 
computer system useful. These requirements may be 
achieved by a method, system, apparatus, and data 
structure for strongly encapsulating an application and 
separating this representation from the runtime repre- 
sentation of the application. This encapsulated form is 
referred to as the Working Definition of the application. 
The defining characteristics of the application may be 
structured and managed within the application's Work- 
ing Definition. The defining characteristics define the 
persisted state, settings, and structures required to build 
a valid representation of the application within its target- 
ed computer system. This valid representation is re- 
ferred to as the Runtime Representation of the applica- 
tion, and does not necessarily differ from what an in- 
stalled application looks like within a computer system 
today. 

[001 1 ] One embodiment of such an arrangement has 
a memory for storing data for access by an application 
program being executed on a data processing system 
comprising: a data structure stored in said memory, said 
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data structure including: defining characteristics of an 
application program wherein the defining characteristics 
of the application comprise elements sufficient to con- 
struct a valid runtime representation of the application 
program within the data processing system. 
[001 2] There is, a need for a method, system and ap- 
paratus that automatically detects damaged files and 
applications and restore them to their proper condition. 
[001 3] According to one aspect of the present inven- 
tion, a method of detecting and repairing damaged por- 
tions of a computer system is provided, the method com- 
prising: detecting a change to the computer system; 
comparing the change to working definitions for each 
application installed on the computer system; wherein 
the working definitions comprise a set of constraints 
placed upon the computer system by each application 
installed on the computer system; and responsive to a 
determination that the change is in conflict with the set 
of constraints, modifying a persistent storage so as to 
resolve the conflict. 

[0014] According to a second aspect of the present 
invention, a computer program product in computer 
readable media for use in a data processing system for 
detecting and repairing damaged portions of a computer 
system is provided , the computer program product com- 
prising: first instructions for detecting a change to the 
computer system; second instructions for comparing the 
change to working definitions for each application in- 
stalled on the computer system; wherein the working 
definitions comprise a set of constraints placed upon the 
computer system by each application installed on the 
computer system; and third instructions, responsive to 
a determination that the change is in conflict with the set 
of constraints, for modifying a persistent storage so as 
to resolve the conflict. 

[0015] According to a third aspect of the present in- 
vention, a system for detecting and repairing damaged 
portions of a computer system is provided, the system 
comprising: means for detecting a change to the com- 
puter system; means for comparing the change to work- 
ing definitions for each application installed on the com- 
puter system; wherein the working definitions comprise 
a set of constraints placed upon the computer system 
by each application installed on the computer system; 
and means, responsive to a determination that the 
change is in conflict with the set of constraints, for mod- 
ifying a persistent storage so as to resolve the conflict. 
[0016] The present application provides a method, 
system, and apparatus for detecting and repairing dam- 
aged portions of a computer system. In a preferred em- 
bodiment of the present invention, a damage detection 
and repair facility monitors and detects changes to the 
computer system. The damage detection and repair fa- 
cility compares these changes to the set of constraints 
defined by the working definitions for each application 
installed on the computer system. The working defini- 
tions define the invariant portions of each application 
and define the constraints placed upon the computer 



system by each application. Responsive to changes that 
are in conflict with this set of constraints, the damage 
detection and repair facility makes such changes in the 
persistent storage so as to resolve these conflicts. This 
5 may be done, for example, by repairing a damaged file, 
installing a missing driver, or adjusting an environment 
variable. 

[0017] In carrying out the method, or utilising the com- 
puter program product or the computer system the cor- 
10 rect version of the file may be retrieved from a server. 
This server may be accessed via a network and the net- 
work may be an Internet. 

[0018] The novel features believed characteristic of 
the invention are set forth in the appended claims. For 
'5 a better understanding of the invention, however, refer- 
ence will now be made, by way of example, accompa- 
nying drawings, wherein: 

Figure 1 depicts a block diagram illustrating a basic 
20 prior art computer architecture structure; 

Figure 2 depicts a block diagram of a data process- 
ing system in which the present invention may be 
implemented; 

25 

Figure 3 depicts a block diagram of a personal dig- 
ital assistant (PDA) in which the present invention 
may be implemented; 

30 Figure 4A depicts a block diagram illustrating a da- 
ta structure for strongly encapsulating an applica- 
tion in accordance with the present invention; 

Figure 4B depicts a block diagram of a new model 
35 for a computer architecture in accordance with a 
preferred embodiment of the present invention; 

Figure 5 depicts a portion of XML code demonstrat- 
ing one method the requirements part of the work- 
40 jng definition may be represented in accordance 
with a preferred embodiment of the present inven- 
tion; 

Figure 6 depicts a block diagram illustrating a meth- 
45 od of automated damage detection and repair with- 
in a computing system in accordance with a pre- 
ferred embodiment of the present invention; 

Figure 7 depicts a flowchart illustrating an exem- 
50 piary method of implementing a damage detection 
and repair facility in accordance with the present in- 
vention; and 

Figure 8 depicts a flowchart illustrating an exem- 
55 piary method of executing a strongly encapsulated 
application within a data processing system. 

[0019] With reference now to the figures and, in par- 
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ticular, with reference to Figure 1 , a block diagram illus- 
trating a basic prior art computer architecture structure 
is depicted. Before proceeding, it should be noted that 
throughout this description, identical reference numbers 
refer to similar or identical features in the different Fig- 
ures. 

[0020] All existing computer architectures are pat- 
terned after a core, basic computer architecture 100. 
This core, basic computer architecture is comprised of 
four elements: one or more processors 1 06, one or more 
memory spaces 1 04, one or more mechanisms for man- 
aging input/output 108, and one or more mechanisms 
for defining persistence 102. The Processor(s) 1 06 per- 
form^) the computations and instructions of a given ap- 
plication by loading its initial state into memory from the 
persisted image for that application. 
[0021 ] Persistence 1 02 is the persisted storage of the 
applications apart from memory 104. The basic nature 
of computer systems requires that all applications be 
stored somewhere. Even if a person types a program 
into a computer system every time they wish to use that 
program, the program is always stored somewhere, 
even if that storage is in someone's head. How an ap- 
plication is stored does not vary much from platform to 
platform. Applications are stored as, for example, exe- 
cutable files and libraries, files, databases, registry en- 
tries, and environment variables. Typically these files, 
databases, etc. are stored on a physical nonvolatile stor- 
age device such as, for example, Read only Memory 
chips, a hard disk, a tape, CD-ROM, or a DVD. Even in 
the most complex applications, the number of distinct 
persisted structures is really rather small, although there 
can be many of each type. 

[0022] Regardless of the application's complexity, it 
depends on its persisted image. If the persisted struc- 
ture is correct, the application will execute. If the persist- 
ed structure is wrong, the application will not execute. 
[0023] With reference now to Figure 2, a block dia- 
gram of a data processing system in which the present 
invention may be implemented is illustrated. Data 
processing system 250 is an example of a computer 
which conforms to the architecture depicted in Figure 
1. Data processing system 250 employs a peripheral 
component interconnect (PCI) local bus architecture. Al- 
though the depicted example employs a PCI bus, other 
bus architectures such as Micro Channel and ISA may 
be used. Processor 252 and main memory 254 are con- 
nected to PCI local bus 256 through PCI Bridge 258. 
PCI Bridge 258 also may include an integrated memory 
controller and cache memory for processor 252. Addi- 
tional connections to PCI local bus 256 may be made 
through direct component interconnection or through 
add-in boards. In the depicted example, local area net- 
work (LAN) adapter 260, SCSI host bus adapter 262, 
and expansion bus interface 264 are connected to PCI 
local bus 256 by direct component connection. In con- 
trast, audio adapter 266, graphics adapter 268, and au- 
dio/video adapter (A/V) 269 are connected to PCI local 



bus 266 by add- in boards inserted into expansion slots. 
Expansion bus interface 264 provides a connection for 
a keyboard and mouse adapter 270, modem 272, and 
additional memory 274. SCSI host bus adapter 262 pro- 
s vides a connection for hard disk drive 276, tape drive 
278, and CD-ROM 280 in the depicted example. Typical 
PCI local bus implementations will support three or four 
PCI expansion slots or add-in connectors. 
[0024] An operating system runs on processor 252 
and is used to coordinate and provide control of various 
components within data processing system 250 in Fig- 
ure 2. The operating system may be a commercially 
available operating system such as JavaOS For Busi- 
ness or OS/2, which are available from International 
Business Machines Corporation. Those of ordinary skill 
in the art will appreciate that the hardware in Figure 2 
may vary depending on the implementation. For exam- 
ple, other peripheral devices, such as optical disk drives 
and the like may be used in addition to or in place of the 
hardware depicted in Figure 2. The depicted example 
is not meant to imply architectural limitations with re- 
spect to the present invention. For example, the proc- 
esses of the present invention may be applied to a mul- 
tiprocessor data processing system. 
[0025] Turning now to Figure 3, a block diagram of a 
personal digital assistant (PDA) is illustrated in which 
the present invention may be implemented. A PDA is a 
data processing system (i.e., a computer) which is small 
and portable. As with the computer depicted in Figure 
2, and as with all computers, PDA 300 conforms to the 
computer architecture depicted in Figure 1 . The PDA is 
typically a palmtop computer, such as, for example, a 
Palm VII 6 , a product and registered trademark of 3Com 
Corporation in Santa Clara, California, which may be 
connected to a wireless communications network and 
which may provide voice, fax, e-mail, and/or other types 
of communication. The PDA 300 may perform other 
types of facilities to the user as well, such as, for exam- 
ple, provide a calendar and day planner. The PDA 300 
may have one or more processors 302, such as a mi- 
croprocessor, a main memory 304, a disk memory 306, 
and an I/O 308 such as a mouse, keyboard, or pen-type 
input, and a screen or monitor. The PDA 300 may also 
have a wireless transceiver 310 connected to an anten- 
na 31 2 configured to transmit and receive wireless com- 
munications. The processor 302, memories 304, 306, 1/ 
O 308, and transceiver are connected to a bus 314. The 
bus transfers data, i.e., instructions and information, be- 
tween each of the devices connected to it. The I/O 308 
may permit faxes, e-mail, or optical images to be dis- 
played on a monitor or printed out by a printer. The I/O 
308 may be connected to a microphone 316 and a 
speaker 318 so that voice or sound information may be 
sent and received. 

[0026] The computers depicted in Figu res 2 and 3 are 
examples of computers that conform to the computer 
architecture paradigm depicted in Figure 1 . The sophis- 
tication of the system, number of components, and 
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speed of the processor may vary, but the basic model 
is the same as the architecture 100 depicted in Figure 
1 : means for input and output such as a keyboard and 
display (whether LED or a video display terminal), a 
processor, memory, and persistence. The persistence 
may be, for example, stored on a hard disk or hard wired 
into the system. However, the computers depicted in 
Figures 2 and 3 are merely examples. Other comput- 
ers, in fact all current computers, also conform to this 
model. Examples of other such computers include, but 
are not limited to, main frame computers, work stations, 
laptop computers, and game consoles, both portable 
and conventional game consoles that connect to a tel- 
evision. Examples of game consoles include, for exam- 
ple, a Sony Playstation 6 and a Nintendo Gameboy* 
Playstation is a trademarked product of Sony Corpora- 
tion of Tokyo, Japan. Gameboy is a product and a reg- 
istered trademark of Nintendo of America, Inc. of Red- 
mond, Washington, a wholly owned subsidiary of Nin- 
tendo Co., Ltd., of Kyoto, Japan. 
[0027] The computer of Figure 2 and the PDA of Fig- 
ure 3 are also suitable to implement the data structures, 
methods, and apparatus of the present invention. The 
present invention modifies the computer architecture 
paradigm illustrated in Figure 1 in a way such as to 
present a new computer architecture paradigm with fea- 
tures and advantages as described below. 
[0028] The present invention provides a data struc- 
ture, process, system, and apparatus for allowing appli- 
cations and computer systems to configure and manage 
themselves. The present invention also provides a proc- 
ess, system, and apparatus for creating encapsulated 
applications with controlled separation from an applica- 
tion's runtime representation. This separation is critical 
and necessary. The application's Encapsulation is pro- 
vided by the Working Definition for the application, while 
the runtime image allows the application to execute 
within traditional execution environments, as defined by 
Windows, Unix, OS/2, and other operating system plat- 
forms. 

[0029] With reference now to Figure 4A, a block dia- 
gram illustrating a data structure for strongly encapsu- 
lating an application is depicted in accordance with the 
present invention. In a preferred embodiment, any soft- 
ware application may consist of the following elements: 
identity 404, code 406, requirements 408, data 410, ar- 
tifacts 412, and settings 414. These elements structure 
the application's defining characteristics. The defining 
characteristics define the persisted state, settings, and 
structures required to build a valid runtime representa- 
tion of the application within its targeted computer sys- 
tem. The application's working definition documents and 
controls each of these elements of the application. 
[0030] The application's identity 404 is defined by the 
application developer, and consists of the application's 
name, version, etc. The identity section 404 may also 
provide documentation, web links, etc. for the applica- 
tion useful both to automated management services and 



users. 

[0031 ] The code 406 represents the executable imag- 
es, files, source code, and any other representation of 
the executable portion of the application that the appli- 

5 cation developer may decide to use. The code section 
406 may also include executable images, files, source 
code, etc. to enable the installation, maintenance, con- 
figuration, un install, etc. of the application through the 
application's life cycle. 

10 [0032] The requirements section 408 defines what di- 
rectory structures, environment variables, registry set- 
tings, and other persisted structures must exist and in 
what form for this application to be properly constructed 
and installed in the persisted image of a computer sys- 

15 tern. The requirements section 408 also details any 
services and applications that are required to support 
this application. The requirements section 408 details 
these concepts as a set of constraints, and also may 
define the order in which these constraints must be re- 

20 solved when such order is required. The requirements 
408 also define the circumstances and constraints for 
the use of application specific installation, maintenance, 
configuration, uninstall, etc. code. 
[0033] The Data section 41 0 defines data tables, con- 

25 figuration files, and other persisted structures for the ap- 
plication. The data section 410 is used to hold Ul pref- 
erences, routing tables, and other information that 
makes the application more usable. 
[0034] The Artifacts 41 2 are the persisted form of the 

30 value provided by the application. Examples of Artifacts 
412 include documents, spreadsheets, databases, mail 
folders, text files, image files, web pages, etc. These are 
the files that contain the user's work ("user" in this con- 
text can be human or application). 

35 [0035] The settings 414 are the persisted structures 
created or modified within the runtime representation 
that are intended to satisfy the requirements for the ap- 
plication. A distinction is drawn between the require- 
ments 408 (which may specify a range of values in a 

40 registry setting or the form a directory structure must 
conform to) and the actual solution constructed in the 
runtime image 100 to satisfy these requirements. 
[0036] The Requirements 408 are provided by the de- 
velopers, application management software, environ- 

45 ments, etc. Settings are made in an effort to resolve 
those requirements, and identify what requirements a 
setting is intended to satisfy. 

[0037] With reference now to Figure 4B, a block dia- 
gram of a new model for a computer architecture 400 is 

so depicted in accordance with a preferred embodiment of 
the present invention. The new computer architecture 
400 of the present invention builds on the standard ar- 
chitecture as depicted in Figure 1. However, the new 
computer architecture 400 also includes an applica- 

55 tion's working definition 402. In a preferred embodiment, 
an application's Working definition 402 is an extensible 
markup language (XML) representation of the identity 
404, code 406, requirements 408, data 410, artifacts 
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412, and settings 414; that is it includes all of the defin- 
ing characteristics for the application. By defining these 
elements, separate from the runtime representation 1 00 
of an application, working definitions 402 provides away 
to strongly encapsulate an application which is compat- 
ible with operating systems that expect applications in 
an un encapsulated form. Working definitions define a 
new, universal picture of a computer system. Working 
definitions do not interfere with any operating system or 
platform because they have no active behavior. Working 
definitions define the application's runtime representa- 
tion 100 by defining what an application is, what it re- 
quires, and what was done to give it what it needs, within 
a given computer system. While working definitions 
have no active behavior, they enable the implementa- 
tion of a variety of automated services. These services 
include application life cycle management, resource 
tracking, application installation, damage detection and 
repair, computer system optimization, etc. 
[0038] Strong encapsulation of state greatly reduces 
the global complexity of a computer system. States such 
as, for example, path requirements, file extensions, reg- 
istry settings, program files, can be maintained in a pure 
state outside of the runtime representation 100. Be- 
cause the runtime version of the application 100 is a re- 
dundant representation, it can be reconstructed, and 
fixed using the encapsulated version of the application 
as the standard. Important modifications can be persist- 
ed back to the application's Working Definition as a 
background task. 

[0039] Working definitions use XML to define a flexi- 
ble format for structuring the critical information about 
an application, thus encapsulating the application. XML 
provides the ability to extend working definitions to fit 
future requirements and, XML, just like the hypertext 
markup language (HTML) of the world wide web, can be 
as simple or as complex as the job requires. The actual 
size of a working definition is very small compared to 
the application it defines, even if the application is just 
a batch file. At the same time, working definitions can 
be used to describe vast, distributed, multi-platform ap- 
plications. 

[0040] Working definitions are platform and technolo- 
gy independent and address universal configuration is- 
sues. Furthermore, working definitions can be used as 
an open standard. Working definitions provide configu- 
ration information to services and to applications as well 
as providing bookkeeping support. 
[0041 ] An application's valid runtime representation is 
one that satisfies a finite, structured set of constraints. 
Therefore, XML is an ideal method because XML pro- 
vides an ideal representation for structured data and 
supports the ability to define links that allow tracking of 
internal relationships or for including references to struc- 
tures defined externally. Furthermore, XML is designed 
to be easily extended and is platform independent. 
[0042] However, XML is not a good representation for 
constant modification and access. The runtime repre- 



sentation for the application provides the application 
with an efficient executable representation. To provide 
an application with an efficient executable representa- 
tion, the XML can detail the required runtime structure 

5 and requirements for the application. Using these in- 
structions, the application can be constructed and exe- 
cuted automatically. Prerequisites, in the proper order 
and with the proper configuration will also be construct- 
ed and executed automatically. 

io [0043] As the application executes, changes made to 
the application's state may be made as they are pres- 
ently, that is, to the runtime representation. The XML 
specifies the important files to be persisted, and this per- 
sistence may be done in the background. The overhead 

'5 is thus very minimal with little effect on the performance 
as viewed from a user's perspective. 
[0044] The nature of the problem of automating man- 
agement and configuration of computer systems re- 
quires a common, computer friendly and people friendly, 

20 complete representation of each software component. 
Without this information, the automated management of 
computer systems is not possible. 
[0045] While the working definitions have been de- 
scribed herein and will be described henceforth with ref- 

25 erence to an XML representation of the application, any 
number of other technologies and approaches might be 
used as well as will be obvious to one of ordinary skill 
in the art. For example, encapsulation could also be im- 
plemented using databases or with Zip files. Also, a da- 

30 tabase could be used for the actual implementation of 
the support for the encapsulation with XML used as a 
transfer protocol. 

[0046] Furthermore, although described primarily 
with reference to constructing Working Definitions using 
35 XML, Working Definitions may be constructed using any 
structured format. Possible choices, for example, in- 
clude the use of other structured forms. These include: 



• Object based technologies (Java Beans, CORBA 
^o objects, C++ objects, etc.). These would have to be 

backed by some sort of database. 

• Object Oriented databases. These are a mix of da- 
tabases and Object based technologies. 

45 

• Functional technologies. One could build a Post- 
Script-like or Lisp-like language (compiled or inter- 
preted) that defines these structures. 

50 • Rule based technologies. Since Working Defini- 
tions generally resolve sets of constraints, this may 
well be the best way of implementing services that 
execute against the constraints that Working Defi- 
nitions define. Working definitions could be con- 

55 structed directly into Rule form, similar to forward 
chaining technologies such as ART, or backward 
chaining technologies such as Prolog. 
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• Tagged formats. XML is an example of a tagged for- 
mat. However, there are other tagged formats that 
would work just as well. Tagged Image Format 
(TIFF), although generally used for defining imag- 
es, may also be used to define Working Definitions 
since the use of custom tags is supported. Addition- 
ally, since TIFF is a binary format, it could hold the 
executable code and binary data. Other tagged for- 
mats include SGML, TeX, and LaTex. 

[0047] In addition to these examples of structured for- 
mats, there are certainly other formats and representa- 
tions that would also work for constructing Working Def- 
initions. Any technology that can 1 ) represent structured 
data, 2) support links to outside sources, and 3) can be 
used across platforms could be used to define Working 
Definitions. 

[0048] With reference now to Figure 5, a portion of 
XML code is shown, demonstrating one method for rep- 
resenting the requirements element of the working def- 
inition, in accordance with a preferred embodiment of 
the present invention. The portion 500 of XML depicted 
is only snippet of a representation of the requirements 
element of the working definition and is given merely as 
an example. Furthermore, this portion 500 of XML is 
overly simplified, but does demonstrate how this infor- 
mation might be represented. 

[0049] Platform tag at 502 reflects the requirement of 
the application that the platform be an xx86 type of com- 
puter, such as, for example, an Intel Pentium 11 class 
computer, running a Windows 95a, Windows 98a, or 
Windows NTa operating system. Pentium is a registered 
trademark of Intel Corporation of Santa Clara, Califor- 
nia. Windows 95a, Windows 98a, and Windows NTa are 
all either trademarks or registered trademarks of Micro- 
soft Corporation of Redmond, Washington. 
[0050] Services tag at 504 indicates that the applica- 
tion requires the TCP/IP and file system services. Pre- 
requisites tag at 506 indicates that the application Ado- 
be Acrobat 8 is a prerequisite (i.e., requirement) for this 
application. Adobe Acrobat is a registered trademark of 
Adobe Systems Incorporated of San Jose, California. 
[0051 ] The registry tag at 508 describes a registry en- 
try. In this example, a Registry entry and a couple of keys 
are defined. 

[0052] The Directory tag at 51 0 describes a couple of 
directories, the "programRoof (which is required, but 
not specified by name) and a subdirectory "program- 
RoofVjclass. 

[0053] Section 512 describes adding the program- 
Root directory to the path environment variable. The di- 
rectory "program RootYjclass is also described as nec- 
essary to be added to the classpath environment varia- 
ble. 

[0054] The <test>...</test> tags in Section 512 de- 
scribe tests that can be used to verify the setup of the 
enclosing section. This is one possible way of describing 
how to use application specific code to maintain an ap- 



plication. 

[0055] Figure 8, is a flowchart illustrating an exem- 
plary method of executing a strongly encapsulated ap- 
plication within a data processing system is depicted in 

s accordance with a preferred embodiment of the present 
invention. To begin, the strongly encapsulated applica- 
tion is transcribed into a runtime image (step 802). The 
defining characteristics embodied in the working defini- 
tion of the encapsulated application are used in conjunc- 

10 tion with system requirements of the platform on which 
the application is to be run are used in transcribing from 
the encapsulated version into the runtime version of the 
application. 

[0056] Next, the runtime image of the application is 
15 translated into an executable version of the application 
by loading the runtime image into memory, thus produc- 
ing an executable version of the application (step 804). 
The computer system's CPU then executes the instruc- 
tion from the executable version of the application that 
20 has been loaded into the memory of the computer (step 
808). 

[0057] With reference now to Figure 6, a block dia- 
gram illustrating a method of automated damage detec- 
tion and repair within a computing system is depicted in 

25 accordance with a preferred embodiment of the present 
invention. Currently, in the prior art, each application is 
responsible for its own integrity within a computer sys- 
tem. Automated facilities for detecting conflicts and re- 
solving them, detecting damaged files or detecting miss- 

30 ing registry entries are severely limited with prior art sys- 
tems. 

[0058] Conflicts and modifications to the runtime en- 
vironment 100 cannot be avoided. They are the natural 
result of using a computer system, since the use of a 

35 computer system naturally leads to installing new appli- 
cations, application updates, production and manage- 
ment of application artifacts, use of temporary files, and 
other changes in the system's configuration. 
[0059] Damage detection and repair facility 602 uses 

40 the requirements defined in the working definitions 604 
of all the installed applications as a set of constraints. 
Whenever changes occur to the runtime environment 
100 or to any of the encapsulated applications, damage 
detection and repair facility 602 detects these changes 

45 and checks them against the set of constraints defined 
by the working definitions of the encapsulated applica- 
tions installed on the computer system. The XML work- 
ing definitions of each encapsulated application define 
the invariant portions of the application and the user's 

50 work which should be persisted as contrasted with tem- 
porary files that need not be persisted. An additional dig- 
itally signed section of the XML application working def- 
inition can provide insurance that checksums and files 
sizes for each of the application's files in the runtime en- 

55 vironment 100 have not been modified. If a file has been 
modified, as detected by damage detection and repair 
facility 602, that file can be repaired with a signed, 
known valid version. 
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[0060] The set of files subject to inspection is very lim- 
ited, since the working definitions define exactly which 
files should be checked. Instead of having to verify each 
and every file, the search can be limited to only those 
files the working definitions identify as critical. More ex- 
haustive checks can be done, but the basic runtime rep- 
resentation verification does not require them. 
[0061 ] With reference now to Figure 7, a flowchart il- 
lustrating an exemplary method of implementing a dam- 
age detection and repair facility, such as, for example 
damage detection and repair facility 602 in Figure 6, is 
depicted in accordance with the present invention. 
[0062] The damage detection and repair facility mon- 
itors the computer system for changes (step 702) and 
determines whether the data processing system has re- 
ceived an indication to power down (step 703). If an in- 
dication to power down the data processing system has 
been received, then the process ends. If no indication 
to power down has been received, then the damage de- 
tection and repair facility determines whether changes 
have been made to any files, settings or encapsulated 
applications (step 704). Searches can be avoided when 
applications use a notification facility in order to facilitate 
this process. However, this kind of interaction with the 
application is not required. If no changes have been 
made, then the damage detection and repair facility 602 
continues to monitor the computer system (step 702). 
[0063] If changes have been made to some aspect of 
the runtime representation of an application as defined 
by that application's working definition, then the damage 
detection and repair facility compares the change 
against the constraints as defined by the set of working 
definitions in the computer system (step 706) and de- 
termines whether the change creates any conflict (step 
708). If the change affects one or more working defini- 
tions with conflict, it is recorded in the settings section 
for the affected application(s) (step 710) and conflicts 
are resolved by restoring or adjusting the runtime rep- 
resentations affected. Changes to temporary files and 
settings (as defined by the working definitions of the ap- 
plications that use them) do not cause conflicts. 
[0064] I n systems where security is very important, an 
optional test (step 71 1 ) for changes outside those de- 
fined as reasonable can be made. In this optional ver- 
sion, if the change does not create any conflict, then the 
damage detection and repair facility determines wheth- 
erthe change affects any working definition defined soft- 
ware component (step 71 1 ). This is done to detect those 
changes outside the defined constraints of the system. 
If the change does affect a working definition software 
component, then the settings of the affected working 
definitions are updated (step 712). If the change does 
not affect any working definition defined software com- 
ponent, then any number of strategies may be used 
(step 713) to address this security concern, including re- 
versing the changes, logging the changes for inspection 
later, or reporting these changes to some monitoring fa- 
cility. The damage detection and repair facility then con- 



tinues to monitor the system (step 702). Thus, the work- 
ing definitions of installed applications allow a computer 
system to be modelled as a set of applications that im- 
pose a set of constraints on the runtime representation 

5 of the computer system. These constraints define all of 
the elements of an application that can possibly be per- 
sisted as described above. When settings change, the 
damage detection and repair facility can evaluate these 
changes against this set of constraints as defined by the 

10 working definitions of each application. If the constraints 
are still met, then the settings can be recorded in the 
settings section of the affected working definitions. If the 
constraints are not met, the settings can be adjusted 
(and recorded) as required to restore the computer sys- 

'5 tern back to its proper configuration. 

[0065] It is important to note that while working defi- 
nitions embody logically the totality of all of the defining 
characteristics of an application, the working definition 
may in fact be implemented as a distributed entity, rather 

20 than the single entity located on an individual machine 
as the present invention has been primarily described. 
Components of it may be accessed via links and may 
be physically stored on servers, hard drives, or other 
media and accessed over buses, the Internet, an intran- 
ts et, or other channels. 

[0066] it is important to note that while the present in- 
vention has been described in the context of a fully func- 
tioning data processing system, those of ordinary skill 
in the art will appreciate that the processes of the 

30 present invention are capable of being distributed in the 
form of a computer readable medium of instructions and 
a variety of forms and that the present invention applies 
equally regardless of the particular type of signal bear- 
ing media actually used to carry out the distribution. Ex- 

35 amples of computer readable media include recordable- 
type media, such as a floppy disk, a hard disk drive, a 
RAM, CD-ROMs, DVD-ROMs, and transmission-type 
media, such as digital and analog communications links, 
wired or wireless communications links using transmis- 

40 sion forms, such as, for example, radio frequency and 
lightwave transmissions. The computer readable media 
may take the form of coded formats that are decoded 
for actual use in a particular data processing system. 
[0067] The description of the present invention has 

45 been presented for purposes of illustration and descrip- 
tion, and is not intended to be exhaustive or limited to 
the invention in the form disclosed. Many modifications 
and variations will be apparent to those of ordinary skill 
in the art. The embodiment was chosen and described 

so jn order to best explain the principles of the invention, 
the practical application, and to enable others of ordi- 
nary skill in the art to understand the invention for vari- 
ous embodiments with various modifications as are suit- 
ed to the particular use contemplated. 

55 
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Claims 

1 . A method of detecting and repairing damaged por- 
tions of a computer system, the method comprising: 

detecting a change to the computer system; 
comparing the change to working definitions for 
each application installed on the computer sys- 
tem; wherein the working definitions comprise 
a set of constraints placed upon the computer 
system by each application installed on the 
computer system; and 

responsive to a determination that the change 
is in conflict with the set of constraints, modify- 
ing a persistent storage so as to resolve the 
conflict. 

2. A computer program product in computer readable 
media for use in a data processing system for de- 
tecting and repairing damaged portions of a com- 
puter system, the computer program product com- 
prising: 

first instructions for detecting a change to the 
computer system; 

second instructions for comparing the change 
to working definitions for each application in- 
stalled on the computer system; wherein the 
working definitions comprise a set of con- 
straints placed upon the computer system by 
each application installed on the computer sys- 
tem; and 

third instructions, responsive to a determina- 
tion that the change is in conflict with the set of 
constraints, for modifying a persistent storage 
so as to resolve the conflict. 

3. A system for detecting and repairing damaged por- 
tions of a computer system, the system comprising: 

means for detecting a change to the computer 
system; 

means for comparing the change to working 
definitions for each application installed on the 
computer system; wherein the working defini- 
tions comprise a set of constraints placed upon 
the computer system by each application in- 
stalled on the computer system; and 
means, responsive to a determination that the 
change is in conflict with the set of constraints, 
for modifying a persistent storage so as to re- 
solve the conflict. 

4. A method according to claim 1 further comprising; 
or a computer program product according to claim 
2 having instructions for; or a system according to 
claim 3 having means for: 

responsive to a determination that the change 



does not create a conflict with the set of constraints, 
updating settings in the working definitions of affect- 
ed applications. 

5 5. Amethod, computer program product or system ac- 
cording to one of the preceding claims, wherein the 
working definition of each application is provided by 
an extensible markup language representation. 

10 6. A method, computer program product or system ac- 
cording to one of the preceding claims, wherein the 
step of modifying the persistent storage comprises 
repairing the runtime image of an application based 
on an encapsulated representation of the applica- 
15 tion. 

7. A method, computer program product or system ac- 
cording to one of the preceding claims, wherein the 
step of modifying the persistent storage comprises 

20 repairing a damaged file using a correct version of 
the file from the working definition. 

8. A method, computer program product or system ac- 
cording to one of the preceding claims, the method 

25 further comprising; the program having instructions 
for or the system having means for: 

responsive to a determination that the change 
does not create a conflict with the set of con- 
so straints, determining whether the change af- 
fects any working definition defined software 
component; and 

responsive to a determination that the change 
does not affect any working definition defined 
35 software component, reversing the change. 

9. A method, computer program product or system ac- 
cording to one of claims 1 to 7, the method further 
comprising; the program having instructions for or 

^o the system having means for: 

responsive to a determination that the change 
does not create a conflict with the set of con- 
straints, determining whether the change af- 
45 fects any working definition defined software 

component; and 

responsive to a determination that the change 
does not affect any working definition defined 
software component, logging the change. 

50 

1 0. A method, computer program product or system ac- 
cording to one of claims 1 to 7, the method further 
comprising; the program having instructions for or 
the system having means for: 

55 

responsive to a determination that the change 
does not create a conflict with the set of con- 
straints, determining whether the change af- 
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fects any working definition defined software 
component; and 

responsive to a determination that the change 
does not affect any working definition defined 
software component, reporting the change to a s 
monitoring facility. 
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f<requirements> 
<plotform> 
<processor>xx86</processor> 

<os>"Windows 95" or "Windows 98" or "Windows NT* </os> 
</platform> 
<services> 
<service >TCP/I P< /servico 
<service>F!Ie System</service> 
</services> 

{<prereqs> 
<application>Acrobat</opplfcotion> 
</prereqs> 

<registryEntry name="HKEy^CURRENT^USER/Software/X.Com M > 
caq J) <key>DebugPort<value>TCP/IP Port#</vaIue></lcey> 
3U0 » <key>Jovo VM<volue>x<test>x gt "1.1 fc 6"</test></value></key> 
</registryEntry> 

<directory name= ,i progromRoot M /> 

<directory nome= ,, jcloss">programRoot , yjcloss"</directory> 
<environmentVor nome=poth> 

<add>bin</odd> 
< / environmentVar> 
512 $ <environmentVar name=closspath> 

<add>jcIoss'7joppNetU[.jor ,, </odd> 
<test>programRoot"/testaosspoth"</test> 
</environmentVar> 
<requirements/> 
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